Wireless Trondheim

Card image cap

What is/was Wireless Trondheim?

Wireless Trondheim used to be a company providing wireless internett access to public spaces around Trondheim, but it has sinced gone through several changes. More on the company's mission can be found on it's linkedin page. I was hired with the express purpouse of learning about IoT systems and hardware by exploring some ideas that were present at the company. The idea was to create a website that would compare the powerconsumption of various IoT sensor systems. And so that was what I tried to do.

El-watch - Neuron sensors

I started out measuring the powerconsumption of a "neuron" developed by El-watch.

Card image cap
Card image cap

Here I was introduced to 3D-printing, and took a liking to OpenSCAD.

After opening up the tiny box, and making my own stand, I did a few mesurments for various distances, and was introduced to the Otii Arc.

The website

This is where I was first introduced to html and js coding, and I am happy to say that I got the hang of it pretty quickly.

Sadly the server running the database was deleted, and without it, setting up the website isn't worth it. And although I haven't tried, I don't really want to attempt to set up the backend again.

I was introduced to GO, spent some time getting used to it, and eventually wrote a script that would pull data from servers that the sensors uploaded to. The data was put into a MySQL database (That I was introduced to, along with DigitalOcean). I then also created another GO script that could send data to my front end.

The nRF52 and RN2483

So far so good. Easy peasy. I knew how to code. But now I was suddenly dealing with hardware.

Card image cap

The goal was to measure the powerconsumption of the RN2483, but it didn't have any sensors. So we used an nRF52 as a sensor that communicated with the RN, and sendt data via the RN. I ran into several dead ends with this task, and learnt a lot about debuging hardware, and writing code for microcontrollers.

There was no library for communication between an nRF and a RN, so I had to write one myself, and I had never written c code, only a bit of c++. Luckily I found an incomplete general library that I attempted to fill in, but there was more than enough work to do. The first problem I really struggeled with was that the RN has been placed ontop of a shield that for some reason (perhaps noise filtering?) used a 5V and-gate between the data pin on the sheild, and the pin to the RN. Since the RN could run off 3.3V and 5V, but the nRF only used 3.3V, the RN powered up normally, sendt signals that I could read, but never responded to anything I sendt. When I tried using an arduino everything worked, but for some reason, when I went back to the nRF, and sendt the exact same signals, I never got any response. The arduino obviously ran of 5V, and that's why it worked, but I had assumed that since the RN powered up with only 3.3V, and all the datasheets said that it would work with 3.3V, that there was something wrong with my code. Eventually, I got some help, and when tracing the dataline on the sheild, we discovered that it passed through some mysterious chip, and I never used that sheild again.

Card image cap

The second large problem I had was that whenever I used my send command function:
sendCommand("some command...");,
I wouldn't send anything. After struggeling with this for some time, I accepted defeat and got some help. My colleauge (more of a Master-Apprentice relationship) noticed that the memmory address of the string that I was sending was located in the flash memory. And after a quick check on the datasheet, he concluded that the UART didn't have access to said memory. One possible workaround would be to store each command as a variable before sending it, but I ended up using memcpy to duplicate the string instead. And luckly, the copy was stored in RAM.

Card image cap

I also got some experience creating custom PCBs. I made a simple breakout for the nRF52, and a motherboard (If it could even be called that) that supported a matrix for choosing between using a usb as a powersource, or any other powersource. This was usefull since we wanted to mesure the powerconsumption of the RN2483, not the nRF52.

Card image cap